1 프로토콜 포지셔닝과 경계
제1장: 프로토콜 포지셔닝과 경계
1.1 iFay 체계에서 CAP의 역할
Control Authority Protocol(CAP)은 iFay 체계에서 단일하고 명확한 핵심 역할을 담당한다: Fay(iFay 또는 coFay)가 인간 호스트(Natural_Person) 또는 공식 직위(Official_Post)의 인가를 받았는지 검증하여 단말 자원(Terminal_Resource)에 합법적으로 접근할 수 있도록 한다.
구체적으로 CAP 프로토콜은 다음 작업을 담당한다:
- 인가 검증: Fay가 단말의 소프트웨어 또는 하드웨어 자원에 접근을 요청할 때, CAP 프로토콜은 Fay가 제시하는 인가 자격 증명(Authorization_Descriptor 또는 Trusted_Ticket)이 합법적이고 유효하며 폐기되지 않았는지 검증한다. 예를 들어, 사용자의 iFay가 휴대폰 카메라를 열어 사진을 찍으려 할 때, 단말은 먼저 해당 iFay가 사용자로부터 카메라 사용 인가를 받았는지 검증해야 한다
- 세션 관리: 인가 검증을 통과한 Fay에 대해 제어 세션(Session)을 생성하고 세션의 완전한 생명주기를 관리한다. 예를 들어, iFay가 인가를 받은 후 브라우저를 조작하기 시작하면, 브라우저를 열고 닫을 때까지의 전체 과정이 하나의 완전한 제어 세션이다
- 제어권 조율: 여러 Fay 또는 Fay와 인간 사용자 간에 단말 자원의 제어권 배분과 인계를 조율한다. 예를 들어, 수동 조종 중인 드론을 Fay에게 넘겨 자율 비행하게 하거나, 두 iFay가 동일한 프린터를 순차적으로 사용해야 하는 경우
- 자원 접근 등급화: 작업 유형(읽기, 쓰기, 실행, 구성)에 따라 자원 접근을 등급별로 관리한다. 예를 들어, iFay가 온도 센서 데이터를 읽는 데는 read 권한만 필요하지만, 에어컨 온도 설정을 변경하려면 write 권한이 필요하다
- 생존 감지: 활성 세션의 생존 상태를 모니터링하고 실효된 세션이 점유한 자원을 적시에 회수한다. 예를 들어, iFay가 네트워크 중단으로 연결이 끊긴 후, 단말이 하트비트 타임아웃을 감지하여 해당 iFay가 점유하고 있던 카메라 제어권을 자동으로 해제하여, 리소스가 "좀비 세션"에 의해 장기간 잠기는 것을 방지한다
CAP 프로토콜은 iFay 체계에서 지능형 에이전트와 단말 자원을 연결하는 핵심 브릿지이다 — Fay가 누구인지, 무엇을 할 수 있는지에는 관심이 없고, Fay가 특정 작업을 수행할 수 있도록 허가받았는지에만 관심을 둔다.
1.2 CAP가 담당하지 않는 역할 범위
역할 경계를 명확히 하기 위해 CAP 프로토콜은 다음 사항을 명시적으로 담당하지 않는다:
- Fay의 신원 생성 및 관리: Fay 엔티티의 등록, 신원 식별자 할당, 신원 속성 유지 등의 작업은 iFay 체계의 신원 관리 서브시스템이 담당하며, CAP는 인가 검증을 위해 신원 정보를 소비할 뿐 신원의 생성과 관리 과정에는 참여하지 않는다. 예를 들어, "이 iFay의 이름이 무엇이고 누구에게 속하는지"는 신원 관리 시스템이 결정하며, CAP는 "이 iFay가 카메라 사용을 허가받았는지"만 관심을 가진다
- Fay의 지능형 추론 능력: Fay가 사용자 의도를 이해하는 방법, 작업 단계를 계획하는 방법, 지능형 추론을 수행하는 방법 등의 능력은 Fay 자체의 지능 계층에 속하며 CAP 프로토콜과는 무관하다. CAP는 Fay의 지능 수준에 대해 어떠한 가정이나 요구도 하지 않는다. 예를 들어, iFay가 먼저 브라우저를 열고 항공권을 검색하기로 결정하는 것은 CAP와 무관하며, CAP는 iFay가 실제로 브라우저 열기를 요청할 때만 인가 검증을 수행한다
- 단말 자원의 구체적 비즈니스 로직: 단말의 소프트웨어가 작업 명령에 응답하는 방법, 하드웨어가 구체적 기능을 수행하는 방법 등의 비즈니스 로직은 단말 자원 자체가 구현한다. CAP는 인가 검증과 접근 제어만 담당하며 자원의 구체적 비즈니스 처리에는 개입하지 않는다. 예를 들어, 프린터가 어떻게 레이아웃하고 어떤 잉크 카트리지로 인쇄하는지는 프린터 자체의 비즈니스 로직이며, CAP는 iFay가 프린터를 사용할 권한이 있는지만 검증한다
- 네트워크 통신 프로토콜의 구현: CAP는 인가 검증의 논리적 흐름과 메시지 형식을 정의하지만, 하위 네트워크 전송 프로토콜의 구체적 구현 방식은 규정하지 않는다. 예를 들어, 단말과 iFay_Runtime 간에 WebSocket을 사용하든 gRPC를 사용하든 CAP는 제한하지 않는다
- 단말 운영체제의 내부 보안 메커니즘: 운영체제 자체의 사용자 권한 관리, 샌드박스 격리, 프로세스 보안 등의 메커니즘은 CAP의 관할 범위에 포함되지 않으며, CAP는 운영체제와의 통합 인터페이스를 통해 협력한다. 예를 들어, Android 시스템 자체의 앱 샌드박스 메커니즘은 Android가 관리하며, CAP는 Android가 제공하는 인터페이스를 통해 접근 제어 명령을 내린다
1.3 다른 서브프로젝트와의 관계
CAP 프로토콜은 iFay 체계에서 다음 서브프로젝트와 명확한 상호작용 관계를 가진다:
| 서브프로젝트 | 관계 설명 | 상호작용 경계 |
|---|---|---|
| iFay_Runtime | CAP의 주요 호출자. iFay_Runtime은 Fay 인스턴스의 생명주기 관리와 스케줄링을 담당하며, Fay가 단말 자원에 접근해야 할 때 iFay_Runtime이 대신 제어권 요청을 발행한다 | iFay_Runtime → CAP: 인가 검증 요청 발행; CAP → iFay_Runtime: 검증 결과 및 세션 정보 반환 |
| Registration_Authority | CAP의 신뢰 인프라 의존. Registration_Authority는 단말 하드웨어, 소프트웨어 및 운영체제의 등록을 담당하고 단말에 검증 키(Verification_Key)를 배포한다 | Registration_Authority → 단말: Verification_Key 배포; 단말은 Verification_Key를 사용하여 Authorization_Descriptor의 서명을 검증 |
| Descriptor_Issuer | CAP의 인가 자격 증명 출처. Descriptor_Issuer는 Natural_Person 또는 Official_Post의 인가를 받아 Authorization_Descriptor를 생성하고 발급한다 | Descriptor_Issuer → Fay: Authorization_Descriptor 발급; Fay는 Authorization_Descriptor를 제시하여 단말에 접근 요청을 발행 |
| 신원 관리 서브시스템 | CAP의 신원 정보 출처. CAP는 인가 검증 과정에서 Fay의 신원 식별자를 참조해야 하지만 신원의 생성과 관리에는 참여하지 않는다 | 신원 관리 → CAP: Fay 신원 식별자 정보 제공(단방향 의존) |
CAP 프로토콜의 설계 원칙은 자체 역할의 응집성을 유지하는 것이다: 인가 검증과 제어권 관리만 수행하고, 신원 관리, 지능형 추론, 자원 비즈니스 로직 등의 역할은 체계 내 다른 서브프로젝트에 맡긴다.
1.4 적용 시나리오
CAP 프로토콜의 핵심 적용 시나리오는: iFay가 인간 호스트의 단말을 인수하여 인간처럼 단말의 소프트웨어를 사용하고 단말의 하드웨어를 호출하는 것이다.
이 시나리오에서 인간 호스트(Natural_Person)는 자신의 단말 장치에 대한 부분적 또는 전체 제어권을 iFay에게 부여하고, iFay가 대신 단말의 클라이언트 소프트웨어(브라우저, 이메일 클라이언트, 오피스 소프트웨어 등)와 하드웨어 장치(카메라, 마이크, 저장 장치 등)를 조작한다. CAP 프로토콜은 이 과정에서 다음을 보장한다:
- 인가 합법성: 단말이 iFay가 실제로 인간 호스트의 인가를 받았는지 검증할 수 있으며, 인가되지 않은 불법 접근이 아님을 확인한다. 예를 들어, 장삼의 iFay가 이사의 노트북을 조작하려 하면, 단말은 이사가 발급한 인가 자격 증명이 없어 접근을 거부한다
- 오프라인 가용성: 단말이 오프라인 상태에 있더라도 iFay가 유효한 Authorization_Descriptor를 보유하고 있으면 인가된 자원에 합법적으로 접근할 수 있다. 예를 들어, 사용자가 비행기에서 비행 모드를 켜도, iFay는 사전에 저장된 오프라인 인가 파일을 사용하여 노트북의 오피스 소프트웨어를 계속 조작할 수 있다
- 다자간 조율: 여러 Fay 또는 Fay와 인간 사용자가 동시에 동일한 단말 자원에 접근해야 할 때, CAP 프로토콜은 제어권 인계 및 자원 접근 모드 관리 기능을 제공한다. 예를 들어, 사용자가 휴대폰으로 사진을 찍고 있을 때 iFay도 문서 스캔을 위해 카메라를 사용해야 하는 경우, CAP 프로토콜이 양자의 사용 순서를 조율한다
- 안전하고 통제 가능: 모든 인가 검증 및 자원 접근 작업은 감사 가능하며, 인가는 언제든지 폐기할 수 있다. 예를 들어, 사용자가 iFay의 비정상적인 행동을 발견하면, 모든 단말 자원에 대한 인가를 즉시 철회할 수 있으며, iFay의 활성 세션은 강제 종료된다
동일한 프로토콜 프레임워크는 coFay 시나리오에도 적용된다 — 협업형 Fay 엔티티가 공식 직위(Official_Post)의 인가를 받아 조직 단말 장치를 인수하여 협업 작업을 수행한다.
1.5 핵심 설계 원칙
CAP 프로토콜은 오프라인 우선, 온라인 보완의 핵심 설계 원칙을 따른다.
오프라인 인가(Authorization_Descriptor)가 핵심 메커니즘이다. 단말 장치는 네트워크 불가용으로 인해 Fay의 인수 권한을 완전히 박탈해서는 안 된다. Fay가 사전에 인간 호스트의 인가를 받았다면, 이 인가 관계는 암호화 파일 형태로 단말 로컬에 저장되어 단말이 오프라인 상태에서도 독립적으로 인가 검증을 완료할 수 있어야 한다. Authorization_Descriptor는 바로 이 이념의 구체적 구현이다 — 단말 로컬에 저장되는 암호화된 인가 기술 파일로, Fay가 인가받은 자원 범위, 권한 유형 및 유효 기간을 포함하며, 단말 측의 Descriptor_Validator가 네트워크 연결 없이도 검증을 완료할 수 있다.
온라인 티켓(Trusted_Ticket)은 보완 메커니즘이다. 네트워크 연결 환경에서 Trusted_Ticket은 실시간 인가 발급 및 폐기 상태 조회 기능을 제공하여 오프라인 인가의 시효성과 폐기 응답 속도 부족을 보완한다. 온라인 서비스가 가용할 때 단말은 Trusted_Ticket을 통해 최신 인가 상태를 획득할 수 있고, 온라인 서비스가 불가용할 때 단말은 자동으로 로컬 Authorization_Descriptor 검증으로 폴백하여 서비스 중단을 방지한다.
이 설계 원칙의 핵심 고려사항은:
- 가용성 우선: 네트워크 중단이 Fay가 작업할 수 없는 이유가 되어서는 안 되며, 오프라인 인가가 기본적인 가용성을 보장한다. 예를 들어, 사용자가 지하철에서 휴대폰 신호가 끊겨도, iFay는 로컬 인가 파일을 사용하여 휴대폰의 오프라인 앱을 계속 조작할 수 있다
- 보안성 강화: 온라인 티켓은 네트워크 연결 시 즉시 폐기 및 동적 권한 조정을 포함한 더 강력한 실시간 보안 보장을 제공한다
- 점진적 저하: 온라인에서 오프라인으로의 전환은 원활하며 서비스의 갑작스러운 중단을 초래하지 않는다. 온라인에서 발급된 Trusted_Ticket은 오프라인 사용을 위해 로컬 Authorization_Descriptor 형식으로 변환될 수 있다. 예를 들어, 사용자가 Wi-Fi 환경에서 온라인 티켓을 통해 iFay에게 카메라 사용을 인가한 후, Wi-Fi 범위를 벗어나면 해당 인가가 자동으로 오프라인 모드로 전환되어 계속 유효하다